1. Field of the Invention
The present invention generally relates to the interpretation and execution of software instructions by a processor in a computer system. More particularly, the present invention relates to the handling of program instructions for which an exception has occurred. Still more particularly, the present invention relates to an exception handler for a processor that operates more efficiently by disabling fetching for programs that have excepted instructions that have not been resolved.
2. Background of the Invention
A computer system includes a number of components with specialized functions that cooperatively interact to produce the many effects available in modem computer systems. The ability of these various components to exchange data and other signals is vital to the successful operation of a computer system. Typically, components interact by reading or writing data or instructions to other components in the system.
Computer systems typically include a processor (or CPU), random access memory (RAM), and certain peripheral devices such as a floppy drive, a keyboard and a display. These components typically couple together using a network of address, data and control lines, commonly referred to as a “bus.” As computer technology evolved, it became common to connect additional peripheral devices to the computer through ports (such as a parallel port or a serial port), or by including the peripheral device on the main system circuit board (or “motherboard”) and connecting it to the system bus.
The computer operates by having data flow through the system, with modification of the data occurring frequently. Traditionally, the CPU controls most activities in the computer system. The CPU supervises data flow and is responsible for most of the high-level data modification in the computer. In addition, the CPU receives signals from the peripheral devices, reads and writes data to memory, processes data, and generates signals controlling the peripheral devices. The CPU is often referred to as the “brain” of the computer system.
The CPU is a device that operates according to instructions programmed by a designer or programmer. Thus, every operation that the CPU performs is based on one or more programmed instruction. In normal operation, the CPU performs many operations on an instruction, three of which are: (1) it fetches the instruction; (2) it decodes the instruction; and (3) it executes the instruction. In a single “pipeline” CPU architecture, each of these different operations is performed sequentially. To improve CPU performance, modem processor architectures often include a plurality of instruction pipelines to enable the CPU to perform operations on multiple instructions in parallel. To further improve CPU performance, pipelined processors often attempt to predict which instructions should be fetched, decoded and perhaps even executed, even before it is certain that the instruction forms part of the program flow. These predictions typically are performed pursuant to parameters programmed in a prediction algorithm that attempt to determine which branch the program will follow. Thus, in modem CPU designs, the CPU may operate on multiple instructions in different pipelines, and may begin operating on instructions that ultimately are not part of the program.
During normal CPU operation, any error in fetching, decoding, executing or otherwise processing an instruction is referred to as an “exception.” Put simply, an excepted instruction is an instruction that cannot be properly executed by the processor. Thus, for example, if an instruction cannot be accurately decoded, or if an instruction code is not recognized, that is an exception event. Another type of exception occurs when the CPU performs an erroneous prediction of the instruction flow. Thus, if the program branches differently than that predicted by the prediction algorithm, then instructions may be fetched and decoded which are unnecessary to proper CPU operation. The initial divergence from the program flow is typically referred to as an exception.
As processors become faster, they are designed to execute more instructions in parallel. Every instruction has the possibility to except, and thus, as the CPU operates on more instructions, the greater the number of exceptions that will arise. In addition, exceptions can be detected at various stages of the pipeline. As the pipeline becomes longer and wider, more stages or ports are created from which exceptions may be issued. As a further consequence of handling a multiplicity of instructions in parallel, the processor must look further ahead the program flow to fetch and decode instructions that may be needed. The further the CPU must predict ahead, the greater the likelihood that a misprediction will occur, and the more instructions that must be flushed when a misprediction is discovered. It is generally desirable for a CPU to recognize an exception as early as possible, and where necessary, to take corrective steps to handle the exception.
Typically, the exception handler is designed to select the oldest exception to analyze and correct. The oldest exception is the earliest instruction in the program flow. Thus, assume a program is executing with instruction A, B, C, D E and F in sequence. Because most conventional processors fetch instructions in-order, the CPU may fetch instruction B at time t, and may fetch instruction F at time t+4. Because of the out-of-order nature of certain processors, the CPU may actually execute instructions B and F at the same time, although they were brought into the CPU at different times. If instructions B and F both were found to have an exception, the CPU would treat the exception created by instruction B as older than the exception created by instruction F. Because instruction B happened earlier in the program flow, the exception handler would first analyze instruction B for problems.
One problem with existing exception handlers is that they may “handle” bad path instructions. Bad path instructions are instructions that lie in an errant path. Thus, in the example above, if instruction B is a branch misprediction instruction, this is the excepting instruction that starts a bad path. Any subsequent instruction fetched in response to the excepting instruction lies in an errant path. Time and resources devoted to processing instructions in an errant path are wasted, because none of these instructions will be relevant to processing the program once the exception is resolved. This inefficiency also means that the processing of other good instructions was delayed while the errant path instructions were processed.
It would be advantageous if a new architecture and method was created to minimize processing on instructions in errant paths, thereby permitting processor resources to operate more efficiently on good instructions. Despite the apparent advantages, to date no one has developed an exception handler for a processor that effectively minimizes the processing of bad path instructions.